derzeitige Lösung

Wir haben auf die Schnelle das Problem gelöst: Wir geben immer einfach den ''neusten'' Hash zurück. Damit überspringen wir Zyklen. Einziger Nachteil: man kann sich nicht durch die komplette Post-History hangeln.

Einleitung

Hintergrund

Fragt man die Methode getPostDetails(user, hash) nach einem Post, der nicht (mehr) in der Bookmark/Bibtex-Tabelle existiert, so liefert sie ggf. den Hash des nachfolgenden Posts aus der Log-Bookmark/Bibtex-Tabelle zurück.

Szenario

Ich bearbeite einen Post, dabei ändert sich der Hash. Fragt jetzt jemand nach dem alten Hash, so bekommt er einen ''Redirect'' (mittels Exception) auf den neuen Hash. Mittels diesem kann man wieder getPostDetails(user, hash) anfragen und das ggf. wiederholen, bis man den aktuellen Post erwischt (oder bemerkt, dass der Post schließlich gelöscht wurde).

Problem

Wenn sich der Hash beim Ändern des Posts nicht ändern, kommt man da in eine Endlos-Schleife.

Abhilfe

Wir brauchen user+hash+date als Identifikationsmerkmal. Die Methode getPostDetails(user, hash, date) liefert dann den Post mit dem ''größten Datum'' zurück, dessen Datum ''kleiner oder gleich'' dem gegebenen Datum ist. Den aktuellen Post bekommt man dann mittels getPostDetails(user, hash, Date.MAX_VALUE) - d.h., getPostDetails(user, hash) könnte man so einfach an die neue Methode delegieren.

Beispiel

  // gib mir den Post
  getPostDetails('jaeschke', '9218cbda64b88ea0023fdf34879cb694', Date.MAX_VALUE);
  // oops, den gibt's nicht mehr:
  org.bibsonomy.common.exceptions.ObjectMovedException: 
    The requested resource (with ID 9218cbda64b88ea0023fdf34879cb694 and date '2009-10-08 09:23') has been moved to new ID 5e570fd0f3f4d9876ac75c3deb9569ae (2009-10-10 16:55)
  // dann fragen wir nach dem ...
  getPostDetails('jaeschke', '5e570fd0f3f4d9876ac75c3deb9569ae', "2009-10-10 16:55");
  // gibt's auch nicht mehr 
  org.bibsonomy.common.exceptions.ObjectMovedException: 
    The requested resource (with ID 5e570fd0f3f4d9876ac75c3deb9569ae and date '2009-10-10 16:55') has been moved to new ID 5e570fd0f3f4d9876ac75c3deb9569ae (2009-10-10 17:05)
  // gut, dann halt nochmal ...
  getPostDetails('jaeschke', '5e570fd0f3f4d9876ac75c3deb9569ae', "2009-10-10 17:05");
  // OK, hier ist jetzt Schluß: entweder wir bekommen den Post irgendwann mal, oder er wurde halt gelöscht